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(57) Abstract 

Disclosed is a system for administration, on a computer ne- 
twork, of license terms (a so-called license server) for a software 
product (12a, 12b... 12j) provided to said network. Said license 
server (17c, 18a, 18b) being realized by one of the network compu- 
ters and which tasks comprise e.g. tracking of a software product 
(12a, 12b... 12j) usage in the system, issuing usage permits (li- 
censes) to the difTerent network users in accordance with prede- 
fined conditions, monitoring expirations and violations (e.g. the 
maximum number of users simultaneously using a software pro- 
duct) of issued licenses and when necessary, withdrawing issued 
software product licenses. In one embodiment, the system in- 
cludes a policy server database (14) maintained on each node (1 1) 
of the system, where said predefined conditions are specified un- 
der which usage of a software product (12a, 12b... 12j) is permit- 
ted at the respective system nodes (11). Each node also has a poli- 
cy server "daemon" (16) in association with said policy server 
database (14) for interaction with the license server (17c, 18a, 18b) 
in order to enforce license terms for a software producL 
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SYSTEM AND METHOD FOR NETWORK LICENSE ADMINISTRATION 

Technical Field 
The present invention relates to systems and methods 
for controlling and monitoring the use, on computers and 
computer networks, of computer prograuns. 

Background Art _ 




10 As computers have proliferated in availability, the 

investment in computer software has also grown, and there 
have been developed various methods for charging the 
computer user for use of computer software products. 
Typically computer software products are licensed, rather 

15 than sold, to the computer user under various arrangements. 
The simplest common license arrangement gives the user the 
right to use a software product on a single computer, i.e.. 
to employ only one central processing unit (CPU) in 
connection with operation of the software product. Although 

20 many such licenses are for indefinite periods of time, a 
license may also be for a limited duration and extendable, 
so that the entity marketing the product can charge a 
periodic fee (for example, cuinually) for use of the software 
product. Or use may be absolutely time-limited (for 

25 example, one-day) , so that the user may evaluate the 

software product for possible purchase of a regular license. 

Since software can be copied and moved easily from one 
like machine to another, companies have invented methods to 
prevent unauthorized use of their software products. Some 

30 licensors require passwords to activate software on a 
particular machine. The password may be keyed to the 
hardware's identification number as a condition for 
operation of the software. Such systems can effectively 
lock software to a particular machine, but do not address 

35 
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software that is licensed for concurrent or simultaneous 
use. Some licensors use hardware locks that attach to a 
parallel printer port or a serial port on a machine; each 
time the software is activated, it looks for a specified 
5 code, in the hardware lock, as a condition for operation of 
the software. Using hardware locks resolves the problem of 
imauthorized moving of software among machines; however, 
hardware locks do not handle multiple software products on a 
single machine, and they require time and expense to deliver 

10 to the end user* 

When computer software products are used in a network 
environment (which may include computers running in various 
roles as workstations and servers of various types linked 
together over a data path) , additional licensing challenges 

15 are present- For example, a network may permit a user at 
one node (which may be a terminal or workstation, for 
instance) to utilize a software product running at another 
node (which may be the network server or even another work- 
station) . Consequently, the terms of the single-computer 

20 type of software license might not cover the usage of the 
software product on the network, or worse still (from the 
point of view of the licensor) might actually permit such a 
usage without additional compensation to the licensor. One 
approach to network licensing is to grant permission to use 

25 the program based on all of the nodes on the network, and to 
require a license for each node. Then typically the license 
fee may be increased as the number of nodes on the network 
increases. Another approach bases the license fee for a 
software product rxinning on a network on the total number of 

30 individual users who might actually run the software, 

regardless of the number of nodes either on the network or 
running the software product at a given time. These 
approaches, however, have usually required the cooperation 
of the licensee, because additional nodes may be added to 

35 the network, or additional users may utilize the software, 
without the knowledge of the licensor, who is typically not 
present on the premises of the licensee. The licensor may 
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reserve the right to audit the licensee's site, but such an 
audit is intrusive, expensive, and may alienate potential or 
actual customers for licenses. Although other approaches 
exist under which one might charge a single fee per server 
5 or per site or per entity, often on an individually 

negotiated basis, these approaches are often impractical or 
inflexible, in that they also typically do not take into 
account the possible wide variation over time in the number 
of nodes or users and also require reliance on licensee 
1 0 cooperation . 

The same circumstances that make license enforcement 
difficult for the licensors of software products for a 
network environment also make license compliance difficult 
for the conscientious administrator, for example, of a 
15 Management Information System (MIS) or Computer Aided Design 
(CAD) department of a company using software products. The 
administrator may be called upon to ensure that the nxamber 
of workstations using a variety of software products in a 
network environment complies with the terms of a variety of 
20 license agreements. Such an administrator may have to 
develop and promulgate a series of directives about the 
terms of permitted workstation usage and must depend 
primarily upon the goodwill and voluntary compliance of unit 
personnel with such directives. 
25 Recently it has become practical in some network 

environments to determine and limit the number of nodes that 
may access a software product at a given time, and to charge 
a license fee based on the maximum nximber of nodes that are 
permitted to use the software product concurrently. This is 
30 called "concurrent licensing". In these environments, a 
computer program, acting as "librarian" and running on a 
computer node designated as a license server, is typically 
used to distribute license keys (sometimes called "tokens") 
over the network to nodes requesting access to run a 
35 software product; the number of keys is tracked by the 
librarian; and if at a given time, the permitted maximiam 
number of keys would be exceeded by usage of the software 
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product on a requesting node, the node can be denied, at 
such time,, access to invoke the software product. 



Examples of software-based concurrent licensing 
arrangements may be found in Unix applications running in 



5 connection with software products sold under the trademarks 
NetLS (available from Gradient Technologies, Xnc, , 577 Main 
Street, Suite 4, Hudson, Massachusetts 01749), and SunLic 
j (availeible from Sun Microsystems, Inc., Mountain View, 

/ California) , and Flexible License Manager (available from 
/ 10 Highland Software, Inc., 1001 Elwell Court, Palo Alto, 
I California 94303 ) . r~However tnese arrangements suffer ^ronT 



mechanisms for tracking which nodes have been given keys to 
run a given software product and the number of keys 

15 available for running such software product. However, it is 
up to the designers of each software product to program such 
product to implement the terms of any license agreement, 
and, in particular, to program into the product calls to the 
NetliS software to provide information to the computer 

20 running the software product and to write code in the 

applicable product to prevent use of the product when the 
license terms have not been obeyed. Thus a computer system 
utilizing ten different software products that rely on NetLS 
for license enforcement will generally have ten different 

25 substantial software portions (one in each computer product) 
to achieve license enforcement. In addition to this 
complexity, if the license server running NetLS fails, of if 
the network itself fails, then a workstation loaded with the 
software product cannot run the software product, since the 

30 product requires NetLS interaction to be activated. 

The foregoing difficulties are applicable generally not 
just to NetLS but to "metering software" generally. The 
Microcomputer Managers Association has issued a White Paper 
(October 2, 1991), reprinted in Infowbrld, pages 46-42 

35 (October 14, 1991) on the problems of network licensing. 
Commenting on the problem that each software product 
requires its own interface to the metering software (as well 



a number of 




itages. NetLS, for example, includes 
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as possible input of administrative information) , the Vrtiite 
Paper suggests that "[i]t makes much more sense to have a 
single package provide the metering for all application 
software on the network." Infoworld (October 14, 1991) > 
5 supra, at page 51, column 4. Such an approach has its own 
difficulty, however. Each application would still have to 
interface with the single metering package, and the 
interface to such a package must somehow deal with the 
varying licensing terms of each software product. Moreover, 
10 with the metering package running on the license server, a 
failure of the server or the network would prevent all 
software applications from running anywhere on the network. 

Summarv of the Invention 
In a preferred embodiment, the present invention 
15 provides an improved system for administration, on a 

computer network, of license terms for a software product on 
the network. The improved system is of the type having an 
arrangement, such as NetLS, for tracking software product 
usage, associated with one of the computers acting as a 
20 license server. This arrangement permits the license server 
(i) to identify the current set of nodes that are using the 
software product at a given time, (ii) to handle license 
data concerning conditions under which usage of the software 
product is permitted at any given node, and (iii) to 
25 determine whether at any given time the conditions would 

still be satisfied if a given node is then added to this set 
of nodes. The software product may thus include 
instructions to interface with the license server to cause 
enforcement of the license terms. The improvement, in one 
3 0 embodiment, to the system includes a policy server database 
maintained on each node, containing data specifying 
conditions under which usage of the software product is 
permitted on such node. Each node also has a policy server 
"daemon" (which may be implemented in software) in 
35 association with the corresponding policy server database, 
for (i) communicating with the license server, (ii) 
interfacing with both the software product and the 
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corresponding policy server database, (iii) malcing- a 
permission— to-rxon availability determination, with respect 
to local usage of the software product, on the basis of 
applicable data from the license server and the 
5 corresponding policy server database, so that enforcement of 
license terms applicable to the software product at a given 
local node is achieved on the basis of both license policy 
maintained at such local node as well as applicable data 
from the license server, 
10 In a further embodiment, each policy server database 

contains data specifying conditions imder which usage of 
each of a plurality of software products is permitted on the 
node on which the database is maintained. Additionally, 
each policy server daemon interfaces with each software 
15 product. In this manner, enforcement of license terms 
appliceible to each software product at a given node is 
achieved on the basis of both locally maintained license 
policy and applicable data from the license server. 

In a further embodiment, each node has a log file 
20 maintained, in association with each policy server daemon, 
to record recent software product usage on that node. The 
policy server daemon is accordingly configured to handle 
instances when data from the license server is 
unavailable — for example, when the computer acting as the 
25 license server is non-operational or when the network is 
non-operational. In particular,^ the policy server daemon 
may permit a node to run a software product, in the absence 
of license server data, if the node's log file indicates a 
sufficient level of recent usage of the software product on 
30 the node. The circumstances under which such a permission- 
to-run availability determination is favorable may be 
estcd^lished by the node's policy server database. 

In yet further embodiments, the policy server database 
and the log file may be encrypted. Furthermore the 
35 interface between the policy server daemon and each software 
product may be made secure. When one or more of the 
software products cire sxibject to concurrent licensing 
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restrictions specified in the policy server databases, the 
policy server daemon may be permitted to reserve a 
predetermined time interval over which the applicable node 
has a guaranteed opportunity to utilize a given software 
5 product. The reservation is accomplished by having the 
node's policy server daemon communicate to the license 
server over the predetermined time interval that the node is 
using the given software product, regardless whether the 
software product is actually being used. 

10 It can be seen that the present invention permits a 

single database at each node to specify all of the 
conditions under which the node may access any of the 
software products on the network. Furthermore, as described 
in further detail below, in order to invoke the licensing 

15 administration function carried out in accordance with the 
present invention, each software product need contain only a 
simple and short segment including the instruction: 



ILic-get_license 

20 

followed by parameters identifying license details for the 
particular software product. A branching routine (which may 
made available to all the software products, and called by 
the particular software product after this instruction) then 
25 specifies program flow depending on whether a license is 
available (the remainder of the program can be run) or not 
- (the program operation is terminated and a message is 
displayed to the user) . 

Brief Description of the Drawings 
30. The foregoing features of the invention will be more 

readily understood by reference to the following description 
taken with the accompanying drawings in which: 

Fig. 1 is a block diagram showing operation of a 
preferred embodiment of the invention in a network; 
35 Fig. 2 is a block diagram illustrating the 

interrelation of important modules of the embodiment; 

Fig. 3 is a block diagram of the main logical flow of 
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the computer program used in the embodiment; 

Fig. 4 is a block diagram of the main processing of a 
validated "get license" message; 

Fig. 5 is a block diagram of the manner in which the 
5 policy server database is structured; 

Fig. 6 is a block diagram providing more detail than 
Fig. 4 of the logical flow of the processing of a "get 
license" message; 

Fig. 7 is a block diagram of license acquisition 
10 processing referred to as item 623 in Fig. 6; 

Fig. 8 is a block diagram of clock message processing 
for licenses on the main list of licenses that have been 
established; and 

Fig. 9 is a block diagram of clock message processing 
15 for licenses moved to the recovery list by item 88 of Fig. 
8. 

Detailed Description of Specific Embodiments 
The invention is applicable to computer networks of the 
type having an arrangement, such as NetLS, for tracking 
20 software product usage, associated with one of the computers 
on the network acting as a license server. The present 
embodiment is described with respect to a Unix network; 
however, the software used by the license server in 
implementing such an arrangement, and the particular network 
25 type, are a matter of design choice. 

Fig. 1 shows the manner in which a preferred embodiment 
of the invention may be implemented on a Unix network. Each 
computer node 11 of the network may be running a variety of 
software products, such as PDS (item 12a) , EMS (item 12b) , 
30 and so forth (shown through item 12j). Each of these 

products includes a call "get_license" to the local policy 
server daemon 16 for a determination whether a license is 
available to run the product in question. As used in this 
detailed description, the term "license" refers not to ^ 
35 written document between the licensor and the licensee, but 
rather to the availability of permission to run the software 
product. The local policy server daemon 16 operates at the 



BNSDOCID: <W0 931 1 480A1 _!_> 



BNS page 10 



wo 93/1 1480 



" 9 - 



PCT/US92/10215 



computer node 11 and makes the permission-to-run 
availability determination by reference to its associated 
policy server database 14, also located at the node, to 
identify the rules specifying the circumstances under which 
5 a license would be granted. The daemon 16 also communicates 
over the network with the applicable license server. In 
this figure, three separate license servers are shown: one 
(item 18a) running NetLS; another (item 18b), SunLic; and 
another (item 18c) , Highlands. The license server 
10 communicates with the daemon 16 using the applicable license 
software NetLS (item 17a), SunLic (item 17b), or Highlands 
(item 17c) , and informs the daemon whether usage of the 
software product on the network is such that a license may 
be granted in accordance with the policy established by the 
15 database 14, If so, the daemon 16 reports the license to 
the applicable software product 12, and to the applicable 
license server 18. If there is no successful communication 
with the applicable license server 18, if the database 14 so 
permits, the daemon 16 will consult a log file 15 recording 
20 instances of recent software product usage, and if there has 
been a sufficient level of recent software product usage 
that has been licensed, the daemon will grant a temporary 
user license (TUL) to run the software product. 

The communication between the applicable software 
25 product 12 and the local policy server daemon 16 is handled 
as an interprocess communication in Unix. Here the Unix 
"message" is used as the means of communication, but this is 
a matter of choice, and other means of communication, such 
as pipes or shared memories, may be used. In order to 
30 reduce to risk of tampering by the licensee with the license 
availability determination made by the policy server daemon 
16, the rules database 14 and the log file 15 may be 
encrypted using techniques known in the art. Similarly, the 
message communication from the application to the policy 
35 server daemon 16 can be subject to validation using 

techniques known in the art to assure that the message is 
indeed from the pertinent software product. 
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The embodiment described herein has been implemented 
for use with a variety of types of licenses. (Numerous 
license types may be created and enforced by the invention, 
but the following types are illustrative.) One type is the 
5 concurrent use license. A concurrent use license is issued, 
from the server rxinning the Licensing System (sometimes 
called the "license server" in this description and the 
claims following) , with respect to a software product being 
used on a node in a network. The license server controls 
10 the levels of concurrent usage of the software product. 

Concurrent use licenses are returned to the license server 
when they are no longer needed. For example, if the 
Licensing System on the server permits five concurrent 
licenses for a given software product, then five users on 
15 the network can run the software product concurrently. 

The concurrent use license is actually implemented as 
part of a two-tier structure. The first tier is a "base 
license," and the second tier is a "version-specific" 
license. The base license controls the number of 
20 simultaneous users of a software product. The version 

license controls the version of the software product that 
may be utilized by the user- The base license typically 
expires at the end of each year, and may be renewed. The 
version license typically never expires. The version 
25 license provides a mechanism for controlling how many base 
licenses are for a software product that is under a 
maintenance agreement. As an example, a user may have 
purchased a license to five copies of version A of a 
software product, but kept maintenance on only three copies. 
30 In such a case the user would receive five base licenses 
(which expire each year and were replenished xinless the 
applicable computers were sold) , plus five version A 
licenses that never expire. This user would subsequently 
receive only three version B licenses for the three copies 
35 under maintenance. Under such an arrangement, the user 
could still run five copies of version A of the software 
product, or a mix of version A emd version B software as 
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long as the mix does not exceed five copies in total and 
does not exceed three copies of version B. 

The policy server database file 14 of a computer node 
stores the license requirements for each software product to 
5 be rtin at that node. For each software product, the 

database may identify the number of base license "tokens" 
and version license "tokens", obtained from the server 
mnning the Licensing System, that are necessary for 
operation of that software product on the particular 

10 computer consituting the node, (The particular computer, 
for example, may be particularly fast in processing, and 
therefore a higher license fee may be required for running 
the software product on such computer, resulting here in a 
larger number of tokens required for the base and version 

15 licenses.) 

Another type of license is a node-locked license, which 
is tied to a particular computer node and cannot be used by 
other nodes. The node-locked license token is designated 
for a particular node when created. In a further variation 

20 of the node-locked license, a "reserved" license may be 
established, that is, the policy server daemon may be 
permitted to reserve a predetermined time interval over 
which the applicable node has a guaranteed opportunity to 
utilize a given software product. (The reservation is 

.25 accomplished by having the node's policy server daemon 
communicate to the license server over the predetermined 
time interval that the node is using the given software 
product, regardless whether the software product is actually 
being used. ) 

30 A single use license can be used only for one 

invocation of the software product. Single use licenses are 
useful for emergency situations, peaks in usage, or 
demonstrations. A day use license is similar to a single 
use license, except that a day use license remains available 

35 on the computer node that acquired it for 24 hours after the 
time of acquisition. 

A temporary user license (TUL) , described above, is 



BNSDOCID: <WO. 



_9311480A1 J_> 



BNS page 13 



wo 93/11480 



- 12 - 



PCr/US92/10215 



issued on a temporary basis when the server running the 
Licensing System becomes unavailable. A TUL is designed for 
emergency situations and is grated on a per user, per node, 
per software product, per usage history basis. 
5 Fig. 2 illustrates the structure of a program 

implementing the embodiment of Fig. 1 for a single license 
server running one or more Licensing Systems, such as NetLS. 
The program is written in standard C. A communication 
module 21 handles communication with the various software 

10 products, one of which is here shown as item 26. If the 

software product includes the "get_license" instruction, the 
communication module 21 refers to the licensing dispatch 
module 22. The licensing dispatch module 22, by reference 
to the policy server database 14 and the applicable 

15 Licensing System, makes the license availability 

determination* The Licensing System shown here is No. 1, 
and client portion 25 is accessed by licensing dispatch 22, 
which may access other Licensing Systems depending on the 
software product 26 and information in the policy server 

20 database file 14. The client portion of the Licensing 
System 25 communicates over the network with the server 
portion 251. In the event that there is no successful 
communication with the server portion 26, the communication 
module may trigger the temporary user license (TUL) module 

25 27 to consult with the history log file 15 to determine if 
there is a sufficient level of recent licensed usage of the 
software product at this node to permit the grant of a 
temporary user license (TUL) . In any event, the 
communication module 21 reports the license availcibility 

30 determination by directing a message to the software 
product's process. The communication module is also 
responsible for sending a periodic signal (a "ping") to the 
license seirver to indicate continued use of a license. 
Another module 28 causes recordation of license usage in 

35 license usage file 281 for reporting purposes. A file 252 
of node-locked licenses is maintained locally. The 
communication module 21 is controlled by timer interval 
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handler 29, which in turn receives periodic signals from PS 
driver 291 that has been incorporated into the operating 
system. 

Fig. 3 illustrates the main logical flow of the program 
5 carried out by the communication module 21. After 

initialization 31, the program gets the next message from 
any processes, and, in particular, from any software 
products that may be invoked from the node on which the 
program is running. Next the message is validated (item 
10 33), and then the message is processed (item 34). After 

processing of the current message, the program loops to seek 
the next message again. 

The most important message is "get_license" , and this 
message is processed as shown in Fig. 4. The first step 41 
15 is to determine the availability of a license. The license 
availability determination is made in the licensing dispatch 
module 22. 

After the license availability determination is made as 
shown in step 41 of Fig. 4, if a license is granted, that 

20 fact is reported to the software product in step 43. If the 
license is not granted because of a lost connection to the 
server nanning the Licensing System (determination in step 
44), there is a check to see if usage of the software 
product is possible "under grace", that is, whether there 

25 has been sufficient recent licensed usage of the software 
product at the node to permit granting of a TUL. If so, a 
TUL is granted (step 47). If not, or if the license was 
denied for reasons other than a lost connection, the program 
communicates (step 46) the fact of no license availability 

30 to the software product. 

Additionally, the communication module of the policy 
server daemon may reserve a predetermined time interval over 
which the applicable node has a guaranteed opportunity to 
utilize a given software product. The reservation is 

35 accomplished by having the module communicate to the license 
server over the predetermined time interval that the node is 
using the given software product, regardless whether the 
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software product is actually being used. 

The construction of the policy server database is shown 
in Fig. 5. License prices are initially established by 
management decision in price book 51, which forms the basis 
5 for assigning token values (step 52) required for license 
grant. The license cost to use a software product can also 
vary as a function of the hardware platform (i.e., the model 
of the computer) on which the product is running. 
Accordingly, the platform indicator data 54 and the rules 

10 defining the different types of licenses 53 all form a part 
of the structure of the policy server database 55. In order 
to assure integrity of the database, it is encrypted. 

Fig. 6 is a block diagram providing more detail than 
Fig. 4 of the logical flow of the processing of a "get 

15 license" message. Initially (step 61) , memory is allocated 
for the structure of the applicable license to be added to 
the list of license structures in memory. Unless the 
structure shows a reserved license (tested in block 62) , the 
policy server database file 14 of Figs. 1 and 2 is accessed 

20 (step 621) to determine the applicable license terms. If 
access is successful (tested in block 622), then license 
acquisition processing (described in connection with Fig. 7) 
follows (step 623). 

If, as a result of license acquisition processing, a 

25 license is granted (tested in block 625) r the history log 
file 15 of Figs. 1 and 2 is then updated (step 631) to 
reflect this event. Thereafter, the policy server driver 
291 of Fig. 2 is informed (step 63), the license usage file 
281 of Fig. 2 is updated for use in generating later reports 

30 (step 64), the return status the operation is checked (step 
641) , and a status message is built and sent (step 65) to 
the software product that had included the "get license" 
call. If the return status is a failure (tested in step 
641) , the license structure is removed from memory (step 

35 642) before sending the the status message to the software 
product. 

If, as a result of the license acquisition processing 
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of step 623, a license has not been granted, the error 
messages produced by the Licensing System are analyzed to a 
single reason (step 626) , and the return status for the 
software product is determined. If the embodiment described 
5 herein is not in the enforcement mode (determined in step 
627) , then the return status is simply a warning (generated 
in step 643) . If the embodiment is in the enforcement mode, 
there is a check (step 647) to determine if the connection 
with the license server is lost. If there is no lost 
10 connection, the policy server database file 14 is checked 
(step 646) for the appropriate license failure conditions, 
and then the return status is determined (step 644) . If 
there is a lost connection, processing follows (step 645) , 
to determine on the basis of the history log file 15 and 
15 data in the policy server database file 14 whether a TUL is 
available. If a TUL is available, the return status is a 
warning (step 643) , as in the case when the system is not in 
the enforcement mode. Once the return status has been 
determined, processing is the same as if a license has been 
20 granted; that is, the driver is informed, the license usage 
file is updated, the return status is checked and if 
necessary the license structure is removed from memory, and 
the appropriate status message is built and sent to the 
software product (steps 63, 64, 641, 642, and 65). 
25 If after the determination (step 647) that there is a 

lost connection, and a TUL is not available (step 645) , 
processing loops back to license acquistion processing (step 
623) to attempt again to get a license from the license 
server. If the policy server database file 14 cannot be 
30 successfully accessed in step 621 to determine the relevant 
license rules (a matter checked in step 622) , the processing 
goes to determine (in step 627) whether the system is in the 
enforcement mode and to generate an appropriate return 
status. If in step 62, the license structure shows a 
35 reserved license, access to the policy server database file 
14 is skipped altogether, and the driver is informed (step 
63) directly. 
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Fig. 7 is a block diagram of the license acquisition 
processing referred to as item 623 in Fig. 6. In accordance 
with this processing, there is first sought a "base" license 
token and then a "version" license token, where "base" and 
5 "version" have the meanings described c±>ove following the 
description of Fig. 1. Initially, the policy server 
database file 14 is cycled through to determine the enabled 
base token type (step 71) — for example node-locked, or 
concurrent access, or use once. The Licensing System on 

10 the server is then called (step 711) to seek the designated 
enabled token. If the base token is granted (checked at 
step 712) , the policy server database file 14 is then cycled 
through to determine the enabled version token type (step 
72). If the version token is gremted (checked at step 722), 

15 the retxim is "license gremted" (step 73) . In each case if 
processing through the policy server database is not 
complete (checked for, in the case of the base token at step 
713 and in the case of the version token at steop 723), the 
database in cycled through again, the Licensing System is 

20 called to seek an enabled token, and there is a test to see 
if the token is granted. If the end of the list has been 
reached (tested at step 713 for the base token and 723 for 
the version token) and the applicable token has not been 
obtained, a failure is returned (step 725) . If the base 

25 token has been gremted, but the version token denied, then 
the base token is first freed (step 724) before the failure 
is returned in step 725. 

Fig. 8 is a block diagram of clock message processing 
for licenses on the main list of licenses that have been 

3 0 established. First, a license is picked as part of a cycle 
through the main list of licenses in memory (step 81) . Next 
there is a check whether a process exists for this license 
(step 82) . If there is no process, the license is returned 
to the Licensing System, and associated housekeeping is done 

35 Cstep 821) , and the program then picks the next license 
(step 81) to begin processing again. If it is determined 
that there is a process, then it is determined whether the 
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license needs to be "pinged" to satisfy requirements of the 
Licensing System to keep the license (step 83) . The 
implementation here generates a ping every 10 minutes. If 
no ping is currently necessary, the program again picks the 
5 next license (step 81) to begin processing again. If a ping 
is necessary, it is sent (step 84), and if successful (i.e., 
the Licensing System reports that the license is still valid 
(tested in step 85) , the program again picks the next 
license (step 81) to begin processing again. 

10 If the ping is unsuccessful, a failure counter is 

incremented (step 8 6) , and there is a test (step 87) to 
determine if the failure counter is above an established 
threshhold. If it is, then the failure counter is cleared 
(step 88) and the license in question is moved to the 

15 recovery list (step 89) . If it is not, then the program 
again picks the next license (step 81) to begin processing 
again. 

Fig. 9 is a block diagram of clock message processing 
for licenses moved to the recovery list in step 89 of Fig. 

20 8. First, a license is picked as part of a cycle through 
the recovery list of licenses in memory (step 91) . Next 
there is a check whether a process exists for this license 
(step 911) . If there is no process, any remaining part of 
the license is returned to the Licensing System, and 

25 associated housekeeping is done (step 94) , and the program 
then picks the next license (step 91) to begin processing 
again. A check (in step 912) is made to determine whether 
the exit flag had been set in step 935, and if so, the 
process of the software product (application) is signalled 

30 to exit (step 913) , the exit counter is decremented (step 

914) , and a test (step 915) is made to determine if the exit 
counter has reached zero. If so, the application process is 
killed (step 916) . In either event, the next license is 
picked from the recovery list (91) , and processing for the 

35 next license resumes as before. 

If the exit flag had not been set, then a replacement 
license is sought (step 921) , and a test (922) is made to 
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determine whettier a license has been granted. If a 
replacement license has been gxanted, then 

If a replacement license has not been granted, the 
replacement failure counter is incremented (step 93) and 
5 then tested (step 931) to determine if it is above a 
threshhold (here typically 3) . If it is not above the 
threshhold, then the next license is picked from the 
recovery list (91) , and processing for the next license 
resumes as before. If it is above the threshhold, the 

10 polciy server database file 14 is consulted (step 932) to 
determine whether running of the software product is 
permitted (step 933) . If not, then the exit counter and 
exit flag are set up; if running is permitted, the 
replacement failure coxinter is decremented (step 934) . In 

15 either case, the next license is picked from the recovery 
list (91) , and processing for the next license resximes as 
before. 

Many other implementations of the invention described 
herein are possible. For example, the particular types of 
20 licenses described here are merely examples. The use of 
base and version licenses are thus a matter of design 
choice. The manner in which the failure to obtain a license 
is handled can also be tailored to suit the policies of the 
licensor of the software products in question. 
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Wha1: is claimed Is: 

1. An improved system for administration, on a computer 
network/ of license terms for use of a software product on 
the network, the system being of the type wherein the 

^ 5 network has a plurality of digital computers, each computer 

at a node, in communication with each other over a data 
path, and the system has usage tracking means, associated 
with one of the computers acting as a license server, for 

(i) causing the storage of the number of licenses available 
10 for running the software product on nodes of the network, 

(ii) identifying the current set of nodes with respect to 
which a license has been granted to run the software product 
at a given time, and (iii) determining whether at any given 
time any licenses remain to be granted for permitting an 

15 additional node to run the software product, so that the 
software product may include instructions to cause 
enforcement of the license terms; 

wherein the improvement comprises: 

(a) a policy server database containing data 

20 specifying conditions under which usage of the software 
product is permitted on any given node; and 

(b) policy server means, maintained and operating 
locally as an independent process, on each computer, with 
respect to which the license terms are to be enforced, in 

25 association with the policy server database, for (i) 

communicating with the license server, (ii) interfacing with 
both the software product and the policy server database, 
and (iii) making a permission-to-run availability 
determination, with respect to local usage of the software 

30 product, on the basis of applicable data from the license 
server and the policy server database, so that enforcement 
of license terms applicable to the software product at a 
given local node is achieved on the basis of both license 
policy maintained in the policy server database as well as 

35 applicable data from the license server. 

2. A system according to claim 1, wherein each computer at 
a node with respect to which license terms are to be 
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enforced includes means for maintaining locally a policy 
server database, containing data specifying conditions under 
which usage of the software product is permitted on such 
node. 

5 3- A system according to claim 1, further comprising: 

(c) log means for recording and maintaining a log file 
of recent software product usage on each computer at a node 
vith respect to which license terms are to be enforced, such 
log file being accessible to such policy server means, and 

10 wherein such policy server meeois includes means for making a 
permission-to-run availability determination in the absence 
of data from the license server on the basis of data from 
the policy server database and the log file, so that a 
favorable determination is possible if the log file 

15 indicates a sufficient level of recent usage of the 

pertinent software product on the computer on which such 
policy seirver means is operating. 

4. A system according to claim 2, wherein 

(i) each policy server database contains data 

20 specifying conditions under which usage of each of plurality 
of software products is permitted on the computer on which 
the database is maintained, and 

(ii) each policy server means includes means for 
interfacing with each of the software products, 

25 so that enforcement of license terms applicable to 

each software product at a given local node may be achieved 
on the basis of both license policy maintained at such local 
node as well as applicable data from the license server • 

5. A system according to claim 4, further comprising: 

30 (c) log means, maintained locally in association with 

each policy server means, for recording and maintaining a 
log file of recent software product usage on the computer on 
which such log means is maintained |. such log file being 
accessible to such policy server means, and wherein such 

35 policy server means includes means for making a permission- 
to-run availability determination in the etbsence of data 
from the license server on the basis of data from the policy 
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server database and the log file, so that a favorable 
determination is possible if the log file indicates a 
sufficient level of recent usage of the pertinent software 
product on the computer on which such policy server means is 
5 operating, 

6. A system according to claim 1, wherein the policy 
server database is encrypted. 

7. A system according to claim 5, wherein the policy 
server database and the log file are encrypted, 

10 8. A system according to claim 4, wherein the policy 
server means include means for maintaining a secure 
interface with each of the software products. 
9- A system according to claim 7, wherein the policy 
server means includes means for maintaining a secure 

15 interface with each of the software products, 

10, A system according to claim 4, wherein one of the 
policy server databases includes a limit on the nximber of 
nodes that may simultaneously use a given software product 
and wherein the corresponding policy server means associated 

20 with such policy server database includes reservation means 
for informing the license server, over a predetermined time 
interval, that the node associated with such policy server 
means is using the given software product, regardless 
whether such software product is actually being used, so 

25 that such node will always be available to use such software 
product, despite attempts to use the software product at 
other nodes which if successful would otherwise foreclose 
use at such node of such software product, with the effect 
that the reservation means reserves use of such software 

30 product at such node over the predetermined time interval. 

11. A system according to claim 5, wherein one of the 
policy server databases includes a limit on the number of 
nodes that may simultaneously use a given software product 
and wherein the corresponding policy server means associated 

35 with such policy server database includes reservation means 
for informing the license server, over a predetermined time 
inteirval, that the node associated with such policy server 
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means is using the given software product regardless of 
whether such software product is actually being used, so 
that such node will always be available to use such software 
product despite attempts to use the software product at 
5 other nodes which if successful would otherwise foreclose 
use at such node of such software product, with the effect 
that the reservation means reserve use of such software 
product at such node over the predetermined time interval. 

12. A system according to claim 9, wherein one of the 

10 policy server databases includes a limit on the number of 
nodes that may simultaneously use a given software product 
and wherein the corresponding policy server means associated 
with such policy server database includes reservation means 
for informing the license server^ over a predetermined time 

15 interval, that the node associated with such policy server 
means is using the given software product, regardless 
whether such software product is actually being used, so 
that such node will always be available to use such software 
product, despite attempts to use the software product at 

20 other nodes which if successful would otherwise foreclose 
use at such node of such software product, with the effect 
that the reservation means reserves use of such software 
product at such node over the predetermined time interval. 

13. A computer network comprising: 

25 (a) a plurality of digital computers, each computer at 

a node, in communication with each other over a data path; 

(b) usage tracking means, associated with one of the 
computers acting as a license server, for (i) causing the 
storage of the number of licenses available for rxinning the 

30 software product on nodes of the data path, (ii) identifying 
the current set of nodes with respect to which a license has 
been granted to run the software product at a given time, 
and (iii) determining whether at any given time any licenses 
remain to be granted for pearmitting an additional node to 

35 run the software product; 

(c) a policy server database, maintained locally on 
such computer with respect to which it is desired to enforce 
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license terms applicable to usage of the software products, 
containing data specifying conditions under which usage of 
any given one of the software products is permitted on the 
computer on which the database is maintained; and 
5 (d) policy server means, maintained and operating 

locally, on each computer with respect to which it is 
desired to enforce license terms applicable to usage of the 
software products, and in association with the corresponding 
policy server database, for (i) communicating with the 

10 license server, (ii) interfacing with both (aa) each of the 
software products and (bb) the corresponding policy server 
database, and (iii) making a permission-to-run availability 
determination, with respect to local usage of any given 
software product, on the basis of applicable data from the 

15 license server and the corresponding policy server database, 
so that enforcement of license terms applicable to the given 
software product at a given node is achieved on the basis of 
the license policy maintained at such local node as well as 
applicable data from the license server. 

20 14. A computer network according to claim 13, further 
comprising: 

(e) log means, maintained locally in association with 
each policy server means, for recording and maintaining a 
log file of recent software product usage on the computer on 

25 which such log means is maintained, such log file being 
accessible to such policy server means, and wherein such 
policy server includes means for making a permission-to-run 
availability determination in the absence of data from the 
license server on the basis of data from the policy server 

30 database and the log file, so that a favorable determination 
is possible if the log file indicates a sufficient level of 
recent usage of the pertinent software product on the 
computer on which such policy server is operating. 

15. A computer network according to claim 14, wherein the 
35 policy server database and the log file are encrypted. 

16. A computer network according to claim 12, wherein the 
policy server means includes means for maintaining a secure 
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interface with each of the software products. 
17. A computer network according to claim 15, wherein the 
policy server means includes meauis for maintaining a secure 
interface with each of the software products. 
5 18. A digital storage mediiam encoded with instructions for 
a given computer in a computer network of the type having: 

(i) a plurality of digital computers, each computer at 
a node, in commxinication with each other over a data path; 

(ii) usage tracking means, associated with one of the 
10 computers acting as a license server, for (i) causing the 

storage of the number of licenses available for running the 
software product on nodes of the network, (ii) identifying 
the current set of nodes with respect to which a license has 
been granted to run the software product at a given time, 
15 and (iii) determining whether at any given time any licenses 
remain to be granted for permitting an additional node to 
run the software product, 

the instructions when loaded into the given computer 
establishing : 

20 (a) data structure for a policy server database^ 

maintained locally on the given computer, containing data 
specifying conditions under which usage of any given one of 
the software products is permitted on the given computer; 
and 

25 (b) policy server means, maintained and operating 

locally, on the given computer and in association with the 
policy server database, for (i) communicating with the 
license server, (ii) interfacing with both (aa) each of the 
software products and (bb) the policy server database, and 

30 Ciii) meOcing a permission- to-run availability determination, 
with respect to local usage of any given software product, 
on the basis of applicable data from the license server and 
the policy server database, so that enforcement of license 
terms applicable to the given software product at the given 

35 computer is achieved on the basis of the license policy 

maintained at the given computer as well as applicable data 
from the license server. 
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19. A system, for administration of license terms for use 
of a software product on a computer, comprising: 

(a) a policy server database containing data specifying 
conditions under which usage of the software product is 

5 permitted on the computer; 

(b) policy server means, operating on the computer, in 
association with the policy server database, for (i) 
interfacing with the software product and the policy server 
database and (ii) making a permission-to-run availability 

10 determination, with respect to usage of the software 
product, on the basis of data from the policy server 
database. 
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